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Abstract —In many cases we need to represent on the same 
abstraction level not only system components but also processes 
within the system, and if for both representation different 
frameworks are used, the system model becomes hard to read and 
to understand. We suggest a solution how to cover this gap and to 
reconcile component and process views on system representation: 
a formal framework that gives the advantage of solving design 
problems for large-scale component systems. 

I. Introduction 

Component-based software engineering is one of the largest 
fields of software and system engineering, however, in many 
cases we need to represent on the same abstraction level not 
only system components and the data flows between them 
but also processes within the system. Even if the common 
practice to model parts of a system is to use the component 
view, the representation of system behaviour by modelling pro¬ 
cesses within the system becomes more and more important: 
nowadays the process view and the data flow representation 
are a typical part of the development of interactive or reactive 
systems. Having a process view, we can abstract from several 
aspects of the data flows by focusing on the control flow within 
the system, which gives us the advantage of comprehensi¬ 
ble representation even in the case of large-scale systems. 
However, if we need to have both, process and component, 
views on the system to get a comprehensive system model, 
the gap between these views can reduce to zero the benefit 
of having both kinds of representation. To cover this gap, 
we present a formal model of processes which is compatible 
with the component view: modelling both components and 
processes within the same framework, we not only increase 
the readability of a system model but also can easier ensure 
consistency among these different views on a system. 

On the one hand, this concept can also be related to the IEC 
61499 standard developed as a technology for distributed au¬ 
tomation systems with the decentralised and distributed control 
logic (cf. [1], [2]). This standard is oriented on the develop¬ 
ment of reusable modules for industrial control applications, 
and purposes to use function blocks as the basic constructs. 
Each function block corresponds to an abstract representation 
of a functional unit of software, where local data and the 
behavioural specification are encapsulated within an event-data 
interface. In IEC 61499, modular components have an event 
signal interface (representing a control flow) and data ports 
(representing a data flow), and are coupled in a hierarchical 
manner to arrange more complicated, compositional blocks. 
Thus, the suggested approach can be seen as a formalisation 


of the main parts of the IEC 61499 standard, however, due 
to suggested syntax, we can also switch from an event-based 
specification to a time-triggered one - in both cases we have 
a trigger of some kind, the difference solely is whether the 
trigger is an explicit data/control signal or an information 
about the current time in a system. On the other hand, 
specifying a process view on a system, it is desirable to have a 
possibility of a flexible translation from/to a common Petri Net 
notation (cf. eg., [3], [4]), which allows to focus on the control 
flow analysis within a system and is mainly recognised as a 
modelling language for process representation. Our approach 
enables schematic translation between the suggested process 
view representation and the Petri Net language. 

II. Related Work 

Component-based software engineering utilises a well- 
defined composition theory to enable the prediction of such 
properties as performance and reliability. This is one of the 
largest fields of software and system engineering. There are 
many approaches on component-based development covering 
different aspects and focusing on requirements, quality, timing 
properties etc. (cf. e.g., [5], [6], [7]). Several component-based 
prediction approaches, e.g. Palladio [8], CB-SPE [9], ROBO- 
COP [10] derive the benefits of reusing well-documented 
component specifications (cf. also a survey in [11]). In our 
approach we focus on the questions of combination of com¬ 
ponent/data flow and process views, to reuse most of the 
advantages of both representations and to avoid gaps in having 
these representations as unconsolidated ones. 

There is a large variety of approaches on process represen¬ 
tation which have a lot of similarities as well as differences 
in many aspects such as (co-)algebraic view, composition 
types, kinds of structuring, representation of time, separa¬ 
tion of different kinds of flow, etc. An informal way to 
represent processes is used in the UML (Unified Modeling 
Language, [12]): the concept of activity diagrams supports 
the specification of control flow in terms of choice, iteration, 
and concurrency. However, there is a number of approaches, 
e.g., [13], which aim to formalise the UML semantics in 
different ways. A co-algebraic view on process modelling 
gives, e.g., the coordination language Reo [14] a channel-based 
modelling language that introduces various types of channels 
and their composition rules. By composing Reo channels, we 
can specify connectors to realise some behavioural protocols. 
The main concepts used in this language are the service 
synchronisation and the data flow constraints. 
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Many process description techniques are also based on 
the ideas of Petri Nets [3], [4]. For example, YAWL (Yet 
Another Workflow Language, cf. [15]) was developed by 
taking Petri Nets as a starting point and adding new mech¬ 
anisms on the workflow patterns. A number of architecture 
description languages (ADLs) have been developed to specify 
compositional views of a system on an abstract level, e.g., 
the TrustME ADL [16], which combines software architecture 
specification approaches with ideas of design-by-contract. This 
approach allows capturing of complex behavioural interaction 
patterns, synchronous and asynchronous, between large-scale 
components of software and systems architectures. 

Other approaches formalise work flows using the concept of 
process algebras [17]. The most famous of them are Bergstra’s 
Algebra of Communicating Processes [18], Hoare’s approach 
on Communicating Sequential Processes (CSP) [19], Milner’s 
Calculus of Communicating Systems (CCS, cf. [20]), and 
variants thereof. This kind of techniques do not provide the 
high level of abstraction which is very important in the early 
phases of system development. Nevertheless, general ideas of 
process algebras influence many other methods, and there are 
works aimed to solve the problem with abstract view, e.g., by 
adding graphical notations like in [21]. 

III. Formal Model of Processes 

From the large collection of process description techniques, 
we chose the process language described in [22] as the most 
suitable for our purpose to embed the process view into the 
component representation: this process language combines the 
concept of (de)activating processes via control points, firstly 
introduced in Petri Nets, with the idea of separation of data and 
control flow to enable a proper composition of processes. A 
process is understood there as “an observable activity executed 
by one or several actors, which might be persons, components, 
technical systems, or combinations thereof”: it has one entry 
(activation, start) point and one exit (end) point, what also 
perfectly fits to the main ideas of the IEC 61499 standard: an 
entry point is a special kind of input channel that activates 
the process (the functional block in IEC 61499), where an 
exit point is a special kind of output channel that is used to 
indicate that the process (computation in the fictional block) 
is finished. Our approach allows us to model elementary and 
composed processes in a formal way, to argue about properties 
of composed systems, and easily switch from the process view 
to a classical component view. The hierarchical definition of a 
process gives many advantages for analysis, the formal model 
of a process permits its formal verification, and, moreover, 
provides a formal interpretation for the behaviour of a process 
as a special kind of a component. 

Formal specification frameworks should include predefined 
templates and special alerts helping to avoid the omission of 
assumptions about the systems environment. For this reason 
we specify every component in terms of an assumption and 
a guarantee: whenever input from the environment behaves 
in accordance with the assumption, the specified component 
is required to fulfil the guarantee. Even the application of 


specification templates can make the model development more 
understandable and more appropriate for safety-critical and 
large-scale component systems [23]. The main ideas presented 
in this paper are mostly language-independent, nevertheless 
we prefer to present them using an algebraic language FO¬ 
CUS 57 [24] inspired by FOCUS [25], a framework for formal 
specification and development of interactive systems. Another 
advantage is a well-developed theory of composition. 

We specify for any process P its entry and exit points by 
Entry(P) and Exit(P) respectively, and represent a process P 
(elementary or composed) by the corresponding component 
specification PComp , thus, [P] = PComp. For any process P 
with syntactic interface (Ip > Op), where Ip and Op are sets 
of input and output data streams respectively, we can specify 
7 [p] = {Entry(P)} U Ip and O [pj = {Exit(P)} U Op. 

A process can be defined as an elementary or a composed 
one, where the composition of any two processes P i and P 2 
can be sequential Pi; P 2 , alternate P\ 07*2 or parallel P\ \ \ P 2 , 
and for any process P we can define repetitively composed 
process P Oi pS pec> where Ipspec denotes a loop specifier. We 
treat a process as a special kind of a component that has 
additionally two extra channels (one input and one output 
channel) which are used only to activate the process and to 
indicate its termination, i.e. to represents the entry and exit 
points of the process. 

The formal correlation between the definition of processes 
and components are presented below, separately for elemen¬ 
tary and composite processes. Composite specifications of 
processes (as well as of components) are built hierarchically 
from elementary ones using constructors for composition, and 
can be represented in the graphical or the textual style. 

In this paper we use the following operators to present 
examples of process/component specifications: 

() an empty stream 

(x) one element stream consisting of the element x 
ft .1 the first element of an untimed stream / 
s l the ith time interval of the stream 5 
msg n (s) 5 can have at most n messages at each time interval 

A. Model of an elementary process 

An elementary process corresponds to an elementary speci¬ 
fication that has one special input channel start of type Event 
consisting of one element * as well as one special output stop 
of the same type (input and output points of the process that 
corresponds to the signals process is started and process is 
finished). Using the syntax proposed in this paper, we specify 
the type of these channels only implicitly, and need to have 
the following extensions of a component to model a process: 

• Each input channel (except the activation signal channel) 
c has a corresponding buffer (local variable) cBuf of size 
one (one element buffer), which value will be taking into 
account, when starting the process. 

• If the process is inactive, there are no values on its output 
channels. 



• The component gets a local variable active of type Bool 
to represent whether the process is in active phase. 

We suggest the following framework for process specification. 
Assume a process P has n input channels xi,...,x n and 
m output channels yi ,..., y m (cf. Figure 4 for a general 
specification and Figure 2 for the corresponding component 
specification). Data types of input and output streams are 
denoted by M/i, ..., MI n and MO\ , ..., MO m respectively. In 
the local-section of the specification we introduce all the local 
variables used by the process as well as the buffer variables 
used to store the values of the latest inputs while the process 
is inactive. The initial values of buffers for the input channels 
JCij... ,x n are denoted by Buflniti , ..., Buflnit n . A process 
can also have a number of parameters which can be listed in 
parenthesis. 

The specification section in it Process differs from the section 
in it in the following sense: everything that is defined within 
the in it section must be initialised only once, in the beginning, 
where everything that is defined within the in it Process section 
must be initialised every time the process is (re)started, i.e. 
every time the value of the local variable active is triggered 
from false to true (in a process specification this trigger is used 
implicitly, where in a component specification we specify these 
changes directly). 

To increase readability, we label all transitions in the state 
transition diagram: dealing with specifications or real systems, 
where a diagram could be hardly readable due to its size 
and a large number of state transitions, we need to use 
another representation style. Each table line (in the case of a 
diagram, each transition) can be specified as a single formula 
in the gar-part of the specification, the rewriting scheme 
is straightforward. In addition, we distinguish two types of 
the transition labels by coloured representation: inputs and 
constraints on the current local variables’ values are marked 
blue, outputs and changes of local variables’ values are marked 
green. 


-process P [start, stop] j(Parameters) 

in x\ : MIi " . . . , x n : MI n 

out yi : MOi,...,y m : MO m 


timed_ 


local x\Buf £ MIi ; •••; x n Buf £ MI n 

init xiBuf = Buflniti] •••; x n Buf = Buflnit n 


initProcess InitValuesReqForEveryProcessRestart 


asm Some As sumptions 


gar 

1 PrEnding(x ^, . . . ,x* n ,xiBuf, . . . ,x n Buf) —>■ ext 1 = (*) A 
PrCalcFfx t 1 , . . . ,x? n ,xiBuf, . . . ,x n Buf , 

xi Buf ', . . . , x n Buf' , y \, . . . , y'm) 

2 -i PrEnding (x\, . . . ,x' n ,xiBuf, . . . ,x n Buf) —»■ ext' = () A 
PrCalc(x \, . . . ,x' n ,xiBuf, . . . ,x n Buf , 

XiBuf', . . . , X n Buf', y\ , • • • , y^) 


Fig. 1. Specification of a process P 


- PComp (Parameters) timed - 

in start : Event] xi : Ml i, ...,x n : MI n 

out stop : Event] yi : MO i, ...,y m • MO m 


local active : Bool; xi Buf £ MI i; x n Buf £ MI n 

init active = false; xi Buf = Buflniti] ...x n Buf = Buflnit n 


asm Some As sumptions 


gar 

1 active = true A 

P r Ending (x ^, ..., , Xi Buf, ..., x„Buf) —Y ext' = (*) A 

PCalcFfx\ , ..., A, XiBuf , ..., x n Buf, xi Buf' , ..., x n Buf' , y\ , •••,y t m ) 
A active' = false 

2 active = true A 

—>PrEnding(x t 1 , ..., A, XiBuf, ..., x n Buf ) —>■ ext' = () A 
PCalc(x\ , ..., , XiBuf , ..., x n Buf , XiBuf' , ..., x n Buf' , y\ , •••■ > y t m ) 

A active' = true 

3 active = false A ent' = () — >► 

exr = () A active' = active A y\ = <) A ... A y' m = () 

4 active = false A enf / <) ^ 
InitValuesReqForEveryProcessRestart A 

ext 1 = () A active' = true A A « 0 A ••• A yin = 0 

5 active = false A x\ ^ () —>■ XiBuf' = ft. A 

6 active = false A A = () —> xi Buf' = XiBuf 

5+2n active = false A x' n / () — x n Buf' = ft.x^ 

6+2n flcn've = false A x\ = () — > x n Buf' = x n Buf 


Fig. 2. Specification of a component, representing the process P 


The asm-part of the specification must contain all the as¬ 
sumption about the environment, i.e. all the properties of input 
streams which are necessary for the correct system behaviour. 
The gar-part of the specification contains the description of 
system behaviour: the behaviour of any process in its active 
phase. The condition of the process finishing is defined by the 
relation PrEnding over the received input values. 

The relation PrCalcF describes the calculations of the 
output and buffer values for the case PrEnding holds, however, 
sometimes we can use the same predicate for both cases. By 
the relation PrCalc we represent here all the calculations of 
the output and local values for the current step/time unit and of 
the buffer values for the next step - they have to be performed 
during the time process is active. In some cases we need 
to extend this predicate by calculations of some other local 
variables of the process. 

Below we have presented a general specification of a 
process P following by the corresponding component spec¬ 
ification PComp. The 1st and 2nd formulas in the component 
specification are almost equal to the formulas in the process 
specification: the constraints on the variable active are now 
added explicitly. The behaviour of any process in its inac¬ 
tive phase is defined in the component specification by the 
formulas 3,..., 6 + 2 n. It is the same for any process, and is 
therefore omitted in process specifications. The only exception 
is the formula 4: initialisation of the values of local variables: 

























if it is required for every restart of a process, the corresponding 
constraints should be moved to the initProcess section. 

It is easy to see that a process and a classical component 
specification have a very similar structure and syntax, and one 
can easily change from one view to the other without any 
effort and learning a new language. The same also holds for 
composed processes and components. 

We suggest to represent PrCalc by a state transition diagram 
or the corresponding state transition table (also combining 
it with the representation of PrCalcF ), because a graphical 
specification is, in general, more readable than a plain text 
one. Here is applicable the idea of mode automata, which 
have a long history motivated by real-time design practices 
and methods used in industry in connection with statecharts. 
Maraninchi et al. [26] capture the notion of modes formally 
for a practical extension of the real-time synchronous language 
Lustre and include elements of the well-known I/O-automata. 
Mode automata define synchronous mode automata as a hybrid 
between data-flow and transition systems, and in our case we 
need only a part of their approach: a process in our framework 
has only two modes, Active and Inactive , that correspond two 
possible values of the variable active. To argue about a mode 
of a process P at time interval t we use the predicate active (P, t) 
introduced below. 

In the stream representation we say that streams xi ,..., x n 
are disjoint (denoted by disjoint^!,... ,x n )) iff on every time 
interval i only one of these streams contains messages, i.e. 

Vf e N, i £ [1 ••«] : X- ^ () -> Vy ± i, j £ [l..n] :*• = () 

We can extend this idea to the operation over components and 
processes (as a special kind of components). A component C 
is active on output stream v G 0(C) on the time interval t if 
on this time interval the stream x is nonempty 

active(x)(C, t) = f 3x G ©(C) : x* ^ () 

and it is active only on output stream x on the time interval t 
if on this time interval all other its output streams are empty 

active[x](C, t) = f 3\ x e ©(C) : x* ^ () 

i.e., 3x G ©(C) : x? / () Vy / x, ye ©(C) : / = (). 

Thus, a component C is active on the time interval t if at least 
one of its output streams is nonempty on this time interval: 

rjpf 

active(C,t) = 3 x G ©(C) : active(*)(C, t) 

and respectively a component C is restrictively active with a 
lower/upper hound rh on the time interval t , rh < ||©(C)||, if 
on this time interval any k of its output streams are nonempty, 
where 

• for lower bound, active L r LI (C, t): rb < k , i.e. the situation 
where all of streams are nonempty is allowed, and 

• for upper bound, active ^ (C, t): k < rb , i.e. the situation 
where all of streams are nonempty is allowed, 

• (exact) bound active^ (C,t): k = rb, i.e. an exact number 
of streams should be active. 


active^ (C, t) 

def 

| {x £ O(C) 

active (x )(C, t)} 

> rb 

active (C, t) 

def 

| {v G ©(C) 

active (x )(C, t)} 

< rb 

active (C, t) 

def 

{v G ©(C) | 

active(*) (C, f)} 

= rb 


If W : active^ (C, t) we have the case where all the output 
streams of the component C are disjoint. 

In a similar way we specify predicates over a set S of 
components to express that on the time interval t some of 
the components from this set are active: 


activeS(5, t) = 3 C G S : active(C, t) 


activeS ^ (5, t) 

def 

| {CG5 

| 3x £ O(C) 

: active(x)(C, t)} 

> rb 

activeS ^ (5, t) 

def 

| {CS5 

| e O(C) 

: active(v)(C, t)} 

< rb 

activeS (5, t) 

def 

{C£S\ 

e ©(C) : 

active(v)(C, t)} 

= rb 


activeS [rb\ (S, t) = | {C G S | active ( C, £)} | > rb 
activeS \rb] (S', t) = f | {C G S | active(C, t)} | < rb 

Hpf 

activeS [rb] (S, t) = | {C G S | active(C, t)} \ = rb 
B. Composition of processes 

Assume P and Q be any two processes. The sets of input and 
output channels are defined for processes P and Q as well as 
for the the corresponding components PComp and QComp, i.e. 
the component representation of these processes, PComp = [P] 
and QComp = [Q\, as follows: 

Entry (P) = entP Entry (Q) = entQ 

Exit(P) = extP Exit(Q) = extQ 
Ip i \,..., i m Iq X \,..., Xk 

0 P = oi,..., o n 0 Q =yi,...,y z 

A general graphical representation of composition is presented 
on Figure 3. All the channels representing entry and exit points 
of a process (as well as connectors to merge and to split the 
streams over these channels) are drawn in orange. The details 
of auxiliary component specifications are omitted in this paper, 
cf. the technical report [27]. Having this representation we can 
analyse properties of composed processes by applying a well- 
developed composition theory, elaborated by Broy [28]. 

Among other factors, the purposed representation gives a 
basis for a straightforward analysis of the worst case execution 
time (WCET) of the composed processes, e.g., it is easy to see 
that 

wcet(P\Q) = wcet{P) + wcet(Q), 
wcet(P Oipspec ) = wcetiP ), 

wcet(P || Q) = max{wcet(P), wcet(Q)} + wcet(lk), 
wcet(P(B Q) = max{wcet(P), wcet(Q)} + wcet(@) + wcet(+), 
where wcet{X) denotes the WCET of the process X. Con¬ 
sequently, on some abstraction level the the WCET of the 
components &, @ and + can be treated as 0. 







(a) Sequential Composition P,Q (b) Repetitively Comp. Process 



(c) Simultaneous Composition P \ \ Q (d) Alternative Composition P © Q 
Fig. 3. Composition of Processes P and Q 


Sequentially composed process P;Q (cf. Figure 3a) is the 
simplest variant of the process composition, which requires 
no additional auxiliary components: 

[P(iQ(xi,...,x k ,yi,...,y z )} = 
PComp(entP , z'i,..., z m , extP, o \,..., o n ) A 
QComp(extP , ,..., x k , extQ , yi,..., y z ) 

The entry and exit points are defined in this case by 
Entry (P; Q ) = entP and Exit(P ; Q ) = extQ. 

Repetitively composed process (cf. Figure 3b) can be realised 
in two versions, an autonomous and a non-autonomous one. 
For both cases, the special component Delay can be defined 
in many ways to fulfil the required restart-properties, however, 
in most cases it should represent either a timer or a counter of 
some kind. The important point is here that it should be strict 
causal , i.e. to have at least one time unit delay, to prevent 
Zeno runs [29] for the case the process P is only weak causal. 
In the autonomous version, the entry and the exit points 
are undefined, because the process is started by itself and 
repeated after the time specified by the Delay component: 

[P(ii,...,i m ,oi,...,o n ) Oi pspec ] = 

PComp(entD , u,..., i m , extD , o \,..., o n ) A Delay (extD , entD) 

In the non-autonomous version, the Delay component 
should be specified in more sophisticated way to model not 
only a delay but also react to the start signals from outside, 
as well as to define whether the process can be restarted 
before it was completed. Thus, Entry(P Oipspec) = entP and 
Exit(P Oipspec) = extP. 


[P(/i,..., i m , o \,..., of) Oip Spec ] 

PComp(entD, i \,..., i m , extD , o \,..., of) A 
Delay(entP , extD , extP, entD) 

Simultaneously composed process P || Q (cf. Figure 3c) 
requires an auxiliary components to join the output control 
streams, and and assumes that the processes P and Q can be 
activated next time only in the case when both of them are 
completed, Entry(P\ Q) = entP and Exit(P ; Q) = extPQ: 

[P(ii,...,i m ,oi,...,o n ) || Q(xx k ,yi,...,y z )] = 
PComp(entP , z‘i,..., z m , extP , o i,..., o n ) A 
QComp(entP,x i,... ,x k ,extQ,yi,... ,y z ) A 
&(extP, extQ , extPQ) 

The connector & models the following behaviour: the exit 
point of [P || 2] must be activated iff both processes, P and 
Q have terminated either simultaneously or one after another. 
Its local variables xReady and yReady indicate whether the 
corresponding process have already terminated. If one of these 
processes terminates first, the component sets the correspond¬ 
ing variable to true to indicate that the component is waiting 
for the termination of the second process. Only when another 
process terminates (or if P and Q terminate in the same time 
unit), the component & produces the exit-message and set both 
variables to false. 

Alternate process P ® Q (cf. Fig. 3d, Exit(P ® Q) = extPQ 
and Entry(P ® Q) = entPQ) requires two connectors: @ to 
choose which of the processes should be started (at which 
process should be sent the activation signal), and + to merge 
the output control flow: 

[p(h, ■ ■ ... ,o n ) © Q{x x ,... ,x k ,yi,... ,y z )] = 

P spec (entP , z'i,..., i m , extP , 6>i,..., of) A 
Q spec (entQ,x 1 ,... ,x k ,extQ,y x ,... ,yf) A 
@ ( entPQ , entP , entQ) A +(extP, extQ , extPQ) 

We omit the technical details of the specifications of these 
connectors in this paper. 

IV. Conclusions and Future Work 

This paper introduces a formal model of processes that is 
compatible with the component/ data flow view. This approach 
reflects general constrains of the IEC 61499 standard and 
can can be seen as a formal representation of its main ideas. 
Moreover, it allows to swap from an event-based specification 
to a time-triggered one. To present our theory of process 
modelling, we discussed how a process can be represented 
by a component as well as which properties have the different 
kinds of composition operators. 

This approach is based on human factor analysis within 
formal methods [23], [30], allows to have short and at the 
same time readable specifications, and is appropriate for the 
case the switching to another language is required as well as 
for application of the specification and proof methodology [31] 
aligned on the future proofs already during specification phase 


























= &()= timed = 

in x, y : Event 

out z : Event 


local xReady , yReady : Bool 

init xReady = false; yReady = false 


asm msg 1 (jc) a msg 1 (j) 


gar 



Fig. 4. Specification of the connector & 

to make them simpler and appropriate for application not only 
in theory but also in practice. 

Future research direction comprises extension of the pre¬ 
sented approach by parameterised contracts and reliability as 
well as timing analysis to concurrent systems, combining the 
results introduced in this paper with analysis of the WCET 
of a specified process as discussed in [32] as well as with 
prior work in this direction [33], where timing analysis to 
concurrent systems of both WCET in industry-strength tools 
for large software systems in distributed control, and of 
sampled performance in large-scale runs, were analysed. 

Acknowledgments: We would like to thank Christian Leuxner, 
BMW Group, for numerous discussions on the subject of this 
paper. 

References 

[1] IEC 61499-1, “Function blocks - Part 1: Architecture,” International 
Electrotechnical Commission, 2005. 

[2] V. Vyatkin, “IEC 61499 as Enabler of Distributed and Intelligent Au¬ 
tomation: State-of-the-Art Review,” IEEE Trans. Industrial Informatics, 
vol. 7, no. 4, pp. 768-781, 2011. 

[3] W. Reisig, Petri nets: an introduction. Springer, 1985. 

[4] K. Salimifard and M. Wright, “Petri net-based modelling of workflow 
systems: An overview,” European Journal of Operational Research, vol. 
134, no. 3, pp. 664-676, 2001. 

[5] A. Cechich, M. Piattini, and A. Vallecillo, Eds., Component-Based 
Software Quality: Methods and Techniques, ser. LNCS. Springer, 2003, 
vol. 2693. 

[6] M. Broy, “Multifunctional software systems: Structured modeling 
and specification of functional requirements,” Sci. Comput. Program., 
vol. 75, no. 12, pp. 1193-1214, 2010. 


[7] M. Broy, J. Fox, F. Holzl, D. Koss, M. Kuhrmann, M. Meisinger, 
B. Penzenstadler, S. Rittmann, B. Schatz, M. Spichkova, and D. Wild, 
“Service-Oriented Modeling of CoCoME with Focus and AutoFocus,” 
pp. 177-206, 2008. 

[8] L. Kapova, B. Buhnova, A. Martens, J. Happe, and R. Reussner, “State 
dependence in performance evaluation of component-based software 
systems,” in Performance engineering. ACM, 2010, pp. 37-48. 

[9] A. Bertolino and R. Mirandola, “Cb-spe tool: Putting component-based 
performance engineering into practice,” in Component-Based Software 
Engineering, ser. LNCS, I. Crnkovic, J. Stafford, H. Schmidt, and 
K. Wallnau, Eds., vol. 3054. Springer, 2004, pp. 233-248. 

[10] E. Bondarev, P. de With, and M. Chaudron, “Predicting real-time 
properties of component-based applications,” in In Proc. of the 30the 
EUROMICRO conference, 2004, pp. 40-47. 

[11] S. Becker, L. Grunske, R. Mirandola, and S. Overhage, “Performance 
prediction of component-based systems: A survey from an engineering 
perspective,” in Architecting Systems with Trustworthy Components, ser. 
LNCS, vol. 3938. Springer, 2006, pp. 169-192. 

[12] I. J. G. Booch, J. Rumbaugh, Unified Modeling Language User Guide. 
Addison-Wesley Professional, 2005. 

[13] H. Storrle, “Semantics and verification of data flow in uml 2.0 activities,” 
in ENTCS. Elsevier, 2004, pp. 35-52. 

[14] N. Kokash, C. Krause, and E. de Vink, “Reo + mCRL2: A framework 
for model-checking dataflow in service compositions,” Formal Aspects 
Of Computing, vol. 24, no. 2, pp. 187-216, 2012. 

[15] W. van der Aalst and A. H. M. T. Hofstede, “YAWL: Yet Another 
Workflow Language,” Information Systems, vol. 30, pp. 245-275, 2003. 

[16] H. Schmidt, I. Poernomo, and R. Reussner, “Trust-by-contract: Mod¬ 
elling, analysing and predicting behaviour of software architectures,” J. 
Integr. Des. Process Sci., vol. 5, no. 3, pp. 25-51, Aug. 2001. 

[17] J. A. Bergstra, Handbook of Process Algebra, A. Ponse and S. A. 
Smolka, Eds. Elsevier Science Inc., 2001. 

[18] J. A. Bergstra and J. W. Klop, “Algebra of communicating processes 
with abstraction,” Theor. Comput. Sci., vol. 37, pp. 77-121, 1985. 

[19] C. A. R. Hoare, “Communicating sequential processes,” Commun. ACM, 
vol. 21, no. 8, pp. 666-677, Aug. 1978. 

[20] R. Milner, A Calculus of Communicating Systems, ser. LNCS. Springer, 
1980, vol. 92. 

[21] G. H. Hilderink, “Graphical modelling language for specifying concur¬ 
rency based on CSP,” IEEE Software, vol. 150, pp. 108-120, 2003. 

[22] C. Leuxner, W. Sitou, and B. Spanfelner, “A formal model for work 
flows,” in 8th IEEE International Conference on Software Engineering 
and Formal Methods (SEFM), 2010, pp. 135-144. 

[23] M. Spichkova, “Design of formal languages and interfaces: “Formal” 
does not mean “unreadable”,” in Emerging Research and Trends in In¬ 
teractivity and the Human-Computer Interface, K. Blashki and P. Isaias, 
Eds. IGI Global, 2013, pp. 301-314. 

[24] M. Spichkova, J. Blech, P. Herrmann, and H. Schmidt, “Modeling Spatial 
Aspects of Safety-Critical Systems with FocusST,” 11th Workshop on 
Model Driven Engineering, Verification and Validation, 2014. 

[25] M. Broy and K. Stplen, Specification and Development of Interactive 
Systems: Focus on Streams, Interfaces, and Refinement. Springer, 2001. 

[26] F. Maraninchi and Y. Remond, “Mode-automata: a new domain-specific 
construct for the development of safe critical systems,” Sci. Comput. 
Program., vol. 46, no. 3, pp. 219-254, 2003. 

[27] M. Spichkova, “Focus on processes,” TU Miinchen, Tech. Report TUM- 
11115,2011. 

[28] M. Broy, “Compositional refinement of interactive systems,” J. ACM, 
vol. 44, no. 6, pp. 850-891, 1997. 

[29] R. Gomez and H. Bowman, “Efficient detection of zeno runs in timed 
automata,” in Proceedings of the 5th international conference on Formal 
modeling and analysis of timed systems. Springer, 2007, pp. 195-210. 

[30] M. Spichkova, “Human Factors of Formal Methods,” in IADIS Interfaces 
and Human Computer Interaction (IHCI 2012), 2012. 

[31] M. Spichkova, X. Zhu, and D. Mou, “Do we really need to write 
documentation for a system?” in International Conference on Model- 
Driven Engineering and Software Development, 2013. 

[32] L. Lednicki, J. Carlson, and K. Sandstrom, “Model level worst-case 
execution time analysis for iec 61499,” in 16th International Symposium 
on Component-based software engineering. ACM, 2013, pp. 169-178. 

[33] J. Fredriksson, T. Nolte, M. Nolin, and H. Schmidt, “Contract-based 
reusable worst-case execution time estimate,” in Proceedings of the 13th 
IEEE International Conference on Embedded and Real-Time Computing 
Systems and Applications, 2007, pp. 39-46. 










